The increasing functionality and processing power of terminals, including mobile terminals such as smartphones and tablet computers and collectively referred to as User Equipment (UE), has led to a plethora of different services ranging from ordinary voice calls to advanced “app”-based services. While telecommunication networks have been transformed to packet-switched networks, which group all transmitted data irrespective of content into suitably sized packets, the different services largely differ in Quality of Service (QoS) requirements. Some services have limited interaction with the network, while others need a stable and/or high-performance network to be useful for terminal users. Such usefulness is sometimes measured by defining a Quality of Experience (QoE) or Perceived Quality of Service (PQoS) function.
Conventional means for network operators to measure performance on the network side include counters. The counters provide an overview of the network status, such as the average throughput for a given class of Radio Bearer (RB). For example, a certain class of RB may be used for a certain type of data traffic with associated QoS requirements. The RB class thus defines appropriate settings of network parameters on a Data Link Layer and a Physical Layer of the network. However, to meet QoE requirements, network operators have to survey the QoS over the entire communication link. In a mobile communication network, such an end-to-end QoS includes, and is not limited to, a radio interface of the network.
Furthermore, different services can share one RB, for example because the number of RBs that can be simultaneously set-up is limited by the network. Consequently, network-related counters do not differentiate network usage or network performance by different applications. The network counters thus provide a system overview, but it is often difficult to identify more fine-grained usage problems, which are hidden by the counter aggregation.
More fine-grained conventional techniques for monitoring data traffic, such as Deep Packet Investigation (DPI, also known as Deep Packet Inspection) often cannot associate an investigated data packet with a particular application executed by the UE, for example due to encryption of the data packet or because the DPI algorithm has not yet been updated to recognize data packets of a recently revised or published application.
In the context of network Operation, Administration and Maintenance (OAM), company publication “Creanord EchoNEWS”, July 2009, suggests introducing a Service-VLAN Identifier (S-VID) into Medium Access Control (MAC) frames for end-to-end service monitoring. However, the introduced data scales with the monitored traffic volume and adds to the network traffic, and introducing the S-VID can increase a latency of the data traffic.
Another approach deploys software agents in the UE for measuring different aspects of usage and for reporting measurement results back to the network operators. Such agents are in a position that allows measuring a UE-internal status, for instance a battery level, which is not accessible to the network. However, even within the UE, it might be technically difficult to measure the network performance of other applications, since accessing the terminal is normally limited by construction of an operating system running on the UE, Application Programming Interfaces (APIs), or data security mechanisms. Typically, the APIs of the UE provide access to UE-related metrics, such as location, battery level and event signals. The agent has no access to detailed measurements regarding other applications executed in the UE.
One might consider standardizing certain measurements which the UE is required to report to the network. Such measurements could enhance the network operator's view of the UE and its service operation. However, standardization of application-specific UE-related metrics takes a long time, often several years. It is thus difficult to keep up with the rapid evolution of new services and their usage pattern. Metrics defined by a standard might be obsolete or less useful, once implemented.